1. Field of the Invention
The present invention is related to identification and authentication in computer systems, and more particularly to specifying, implementing, and maintaining control relationships among identities in an identification and authentication management scheme in order to enable temporary access to user data for technical support purposes.
2. Description of the Background Art
In computer technical and customer support, it is often useful to reproduce a problem that is being experienced by a user in order to troubleshoot or resolve the problem. Reproducing a user's problem can be particularly difficult when the support representative is at a different location than the user. For example, the user may call a remote technical support center for assistance in diagnosing and resolving a problem, and the technical support representative is unable to see the user's screen directly. In an attempt to diagnose the problem, the support representative may attempt to duplicate the user's problem on the support representative's own machine.
However, the support representative may require access to the user's own data in order to successfully replicate the problem. When the user's data is stored on a remote repository such as a server, the support representative may attempt to access the user's stored data and perform various tasks on the data in an attempt to replicate, identify, and resolve the problem. This approach is particularly common for online (e.g., web-based) applications, as commonly implemented by an Application Service Provider (ASP), where the user data is typically located on a central server to which the support representative has access. If the data is password-protected, the user may provide the representative with the customer's login identifier and password, so as to permit the representative to access the customer's data.
For some applications, such as financial applications or accounting applications, the user's data is sensitive and/or confidential. A user may be reluctant to provide his or her login and password information to a technical support representative; by providing such information, the user relinquishes control over the data and exposes the data to various security risks. Users may worry that the representative may be careless with the data, or that the password may fall into the wrong hands, or that the data may be misused. In short, once a user has provided his or her login and password information, security risks are introduced, and data integrity is at risk. The user can subsequently change his or her password, but many users do not make these changes, and even if they do, until the change is made, their data is at risk.
Furthermore, in the context of a network-based application, in order for a support representative to most effectively identify a problem with the application, it is desirable for the online application to function in the same manner whether a user or a technical support representative is interacting with it. In particular, when a representative is manipulating data and otherwise interacting with the online application, the application should function in the same manner as it does when the user performs the same operations. If the behavior of the application differs depending on whether a user or a support representative is interacting with it, the support representative may not be able to effectively diagnose the problem. On the other hand, it may be useful, particularly after the fact, to be able to distinguish between user-entered interactions and those entered by the support representative, so that the user can determine which interactions are bona fide and which were entered merely for diagnostic purposes. Conventionally, when the representative interacts with the application using the user's login identifier and password, it may not be possible to distinguish the representative's interactions from the user's interactions.
The Unix operating system provides a “sudo” command, which allows a user to act as a root user or other superuser, when authorized to do so by the actual root user. However, the sudo command has several limitations that render it unsuitable for granting access in a customer support environment as discussed herein. For example, user activity under the sudo command is not tracked separately; thus, it cannot easily be determined which actions were performed by an actual root user and which were performed via the sudo command. In addition, sudo is relatively inflexible, and does not allow relationships among entities such as users, support representatives, or groups, to be established and modified as needed. Also, a sudo session applies only to a single host or machine, and is not capable of controlling user access for a number of machines, services, or applications. In addition, sudo generally applies only in connection with a root user, and not with other arbitrary users. Finally, sudo does not provide sufficient granularity for use in technical support sessions; a user is unable to specify that a support representative be permitted to access particular data associated with the particular user, and to do so in a manner that makes it appear (to the application) as though the activity is under the direction of the particular user.
What is needed, therefore, is an identification and authentication management scheme that maintains control relationships among identities in order to allow a user to dynamically grant or deny permission for a technical support representative to access the user's data, while allowing the user to retain ultimate control over access to the data. What is further needed is a scheme that allows a user to retain such control even when his or her data is stored on a central server.
What is further needed is a scheme that allows interactions entered by the representative to be distinguished from those entered by the user.